Hackers Handbook - Millenium Edition/Hackers Handbook.iso/library/hack99/nt_domain_DoS.txt

Internet Message Format | 1999-03-24 | 11.4 KB

Date: Tue, 2 Mar 1999 16:43:10 -0600
From: Paul L Schmehl <[e-mail]>
To: [e-mail]
Subject: NT Domain DoS and Security Exploit with SAMBA Server

Near the end of November of last year, we notified the SAMBA team,
NTBUGTRAQ and Microsoft of two problems with SAMBA in an NT domain.  The
first was a DoS issue and the second was a logon security issue.

Since that time, we have been corresponding with the Microsoft Security
Response Team and doing extensive testing with SAMBA in a test NT
domain.

Here's our test network parameters:
NT 4.0 SP4 PDC
NT 4.0 SP4 BDC
RedHat Linux 5.1 with SAMBA 1.9.18p5
Windows NT Workstation client
Windows 98 client

Here's the issues:

DoS:
*************
When a SAMBA server is placed in a NT domain and configured as follows in
the smb.conf file:

security=server
password server=[hostname of PDC]
domain controller=[hostname of PDC]
domain logons=yes

domain logons will fail if the PDC is rebooted while the SAMBA server is
still running.  We haven't yet determined *why* this is happening, but
we can tell you *what* is happening.

When the SAMBA server comes on line, it does not appear in the WINS
database, but it *does* appear in Server Manager, and reports itself as
a Windows NT 4.2 Server.  After some period of time (which appears to be
random, but less than 24 hours) it begins to report itself as a BDC
(Windows NT 4.2 Backup.)

At that point, if the PDC is taken down for any reason, it cannot be
brought up again.  When rebooting the PDC it will report there is
already a PDC in the domain and refuse to complete the boot process, yet
Server Manager reports there is*no* PDC in the domain.  It is impossible to
"promote" or "demote" the PDC or to bring it back on line any other way.
At this point, domain logons will begin failing, and the domain essentially
becomes unusable.  The only solution is to kill the SAMBA server, at which
point the PDC will finish booting and the domain will return to normal.

The SAMBA team claims to have avoided this problem in 2.0 according to
Jeremy Allison:

        "This very problem is why my new code in 2.0 explicitly forces
the Samba admin to give the name or IP address of the PDC to authenticate
to, and to allow the name resolution to be forced to
look only in the local hosts file on that machine."

However, we are presently experiencing this problem on our "real" domain
with what appears to be a SAMBA 2.0 server (At least it reports itself as
that in Server Manager.)  I say "appears to be", because we just found the
suspect server today, and I can't confirm all the details of its
configuration at this time.  It definitely disrupted domain logons and
prevented the PDC from rebooting.  (We had one processor suffering from
heat related failure and had to shut down the PDC last Friday to replace a
defective fan.)

Microsoft's Security Response team has looked at this issue and
determined that it cannot be addressed in NT 4.0 due to the insecure nature
of WINS and NTLM.  They claim it will be fixed in Windows 2000:

        "In Windows 2000, DC are located using DNS lookups with
authenticated DNS updates of service location information, so we believe
that homogeneous Windows 2000 networks will not be susceptible to this
problem."

Security:
**************
We all know Windows 95/98 is inherently insecure.  With a SAMBA server
configured as above, it is possible to effect logons on the SAMBA
server.  During our troubleshooting, we noticed that machines all over
campus were being logged on by the SAMBA server, which would query a "real"
DC for the auth and then pass the auth to the client.  This opens an
obvious avenue of attack.

We copied the files from the NETLOGON share on a BDC to the newly
created NETLOGON share on the SAMBA server.  We then wrote a program
spoofing the Windows Logon screen, popped up an error message that
essentially said "your logon had failed, please reenter your
username/password" and were able to get users to enter their
username/password combo into our program, which wrote them to a text file
on the SAMBA server.  (NT Workstations are unaffected by the SAMBA logon
since they won't authenticate without an exchange of tokens.)

The workaround for this security hole, according to Microsoft is:

"1. Locating Valid Logon DCs:

                The workaround here is to use LMHOSTS to point clients
to logon DCs.  There are two Knowledge Base articles, at
http://support.microsoft.com/support/kb/articles/q192/0/64.asp and
http://support.microsoft.com/support/kb/articles/q150/8/00.asp, that
provide info on how to do this.  This is not a complete fix, because the
attacker can still spoof the servers at the IP layer (respond to ARP for
the servers' IP addresses). However, it does mean that any spoofing that is
done must be done at the IP layer, which is harder.

2. Locating Valid Logon Script Shares:

                With Windows NT 4.0 SP3 and Win9x, it is possible to
configure clients to require SMB packet signing.  Once this is done,
only members of some trusted domain can spoof the NETLOGON shares. It also
means that clients will refuse to access shares on servers that don't
support SMB signing, which is any server earlier than NT4/SP3: Win9x
servers or NT3.x servers or Samba servers, for example.  Alternatively, you
could configure LMHOSTS entries on clients for servers that provide logon
script shares.  This is a less effective workaround than SMB signing, but
would allow clients to use downlevel SMB servers."

Our testing has confirmed that this workaround will prevent Win95/98
clients from logging in to the domain through a SAMBA server.

We are still in contact with Microsoft on these issues, and if anything
of note transpires we will notify the list again.

--------------------------------------------------------------------------------

Date: Tue, 2 Mar 1999 22:42:15 -0600
From: Gerald Carter <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
Subject: Re: NT Domain DoS and Security Exploit with SAMBA Server

Paul L Schmehl wrote:
>
> security=server
> password server=[hostname of PDC]
> domain controller=[hostname of PDC]

This is a boolean parameter in the current code (and obselete
I might add)

> domain logons=yes
>
> domain logons will fail if the PDC is rebooted while the
> SAMBA server is still running.  We haven't yet determined
> *why* this is happening, but we can tell you *what* is
> happening

If you set the workgroup to be the same as the domain of
the NT PDC you are referring to, Samba will attempt to
register the workgroup<1b> record (due to domain logons being
enabled). Windows clients use this to locate the DC for their
workgroup

> database, but it *does* appear in Server Manager, and
> reports itself as a Windows NT 4.2 Server.  After some period
> of time (which appears to be random, but less than 24 hours)
> it begins to report itself as a BDC (Windows NT 4.2 Backup.)

The annouce as in Samba 2.0.3 allows you to advertise as a
workstation although the default is still to advertise as a
Server.

The moral is to not enable domain logons if you have an
existing DC.  You don't try to run to PDC's concurrently.
Same here

> Microsoft's Security Response team has looked at this
> issue and determined that it cannot be addressed in NT 4.0
> due to the insecure nature of WINS and NTLM.

correct.  The problem is the dynamic nature in which NetBIOS
names are registered and released.  It is insecure.

> We then wrote a program spoofing the Windows Logon
> screen, popped up an error message that essentially said
> "your logon had failed, please reenter your username/password"
> and were able to get users to enter their username/password
> combo into our program, which wrote them to a text file
> on the SAMBA server.

Don't get this.  So you wrote a mimic program. Not sure how
this relates.  Could do this without Samba.

Again, just to clarify,

* why are you trying to bring up to DC's (Samba and NT)?

* Assuming that you a meaning that anyone on the network
  can do this, I agree it can disrupt service, but is not
  specific to Samba.  Imagine this scenario,

    - I install a Windows NT Server as a PDC off the
      network in your domain.
    - Then I connect it to the network.
    - it will also attempt to take over, right?

What's the difference?  The problem appears to be
netbios name resolutions and regostration and not
Samba.  Aplogies if I misunderstood you post.




Comments and corrections always welcome.
jerry carter
________________________________________________________________________
                            Gerald ( Jerry ) Carter
Engineering Network Services                           Auburn University
[e-mail]             http://www.eng.auburn.edu/users/cartegw

       "...a hundred billion castaways looking for a home."
                                  - Sting "Message in a Bottle" ( 1979 )

--------------------------------------------------------------------------------

Date: Wed, 3 Mar 1999 10:18:08 -0600
From: Paul L Schmehl <[e-mail]>
To: [e-mail]
Subject: Re: NT Domain DoS and Security Exploit with SAMBA Server

Comments below.

--On Tuesday, March 02, 1999, 10:42 PM -0600 Gerald Carter
<[e-mail]> wrote:

[snip]
>
> The moral is to not enable domain logons if you have an
> existing DC.  You don't try to run to PDC's concurrently.
> Same here

Of course.  The problem is SAMBA doesn't exchange tokens with the other DCs
before becoming a member of the Domain Server Group.  This isn't SAMBA's
fault, it's Microsoft's, for not having a secure method to register DCs.

Also, domain logons=yes is the default setting in the smb.conf file, so
this can be done completely without the knowledge of the individual setting
up SAMBA.  This is apparently still true in SAMBA 2.0, because the server I
mentioned in my post took down the domain without the knowledge of the
admin who set it up.
>
[snip]
>
> Don't get this.  So you wrote a mimic program. Not sure how
> this relates.  Could do this without Samba.

How?  You have to have something which is seen by clients as a DC with a
NETLOGON share before you can start processing logons.  You can't do that
with an NT server without knowing the domain administrator password.  You
can do it with SAMBA without any authentication at all.
>
> Again, just to clarify,
>
> * why are you trying to bring up to DC's (Samba and NT)?

We're not.  They do that be default.  And that's my point.  *Anyone* in
your organization can bring up a SAMBA server and take down the domain
(under the right circumstances as posted.)  This has already happened to us
twice, both times without the knowledge or approval of the IR department.

[snip]
>
> What's the difference?  The problem appears to be
> netbios name resolutions and regostration and not
> Samba.  Aplogies if I misunderstood you post.

I'm not blaming SAMBA.  This is obviously a flaw in the fundamental design
of domain security, and Microsoft has acknowledged that.  The only point of
SAMBA being involved is it makes the task much easier because there's no
authentication and token exchange required.
>
>
>
>
> Comments and corrections always welcome.
> jerry carter
> ________________________________________________________________________
>                             Gerald ( Jerry ) Carter
> Engineering Network Services                           Auburn University
> [e-mail]             http://www.eng.auburn.edu/users/cartegw
>
>        "...a hundred billion castaways looking for a home."
>                                   - Sting "Message in a Bottle" ( 1979 )